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(54) DATA RECORDING METHOD, DATA EDITING METHOD, DATA DECODING METHOD, AND 
APPARATUS THEREOF 



(57) A system records an AV stream composed of a 

plurality of record units (RUs) containing independently 
reproducible video units (VUs) of at least video or audio 
and program infonnation (Movie atom) managing the AV 
stream, onto a recording medium. The program infor- 



mation contains a piece of infomnatlon (Edit list atom) 
that manages apoint of junction between the record 
units or between AV streams. In decoding the AV 
stream, decoding is halted or decoders are switched at 
the point of junction, based on the management infor- 
mation on the points of junction, for example. 
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Description 

Technical Field 

[0001] The present invention relates to a data record- 5 
ing method, a data editing method and a data decoding 
method and an apparatus therefor, for recording and re- 
producing data such as video data and audio data to 
and from a random-accessible recording medium such 
as a hard disl<, optical disk, etc. 

Background Art 

[0002] Digital recording and reproducing apparatuses 
for video and audio using disk media have been coming 
into wide use. One of the featured functions of disk me- 
dia, distinct from tape media, is the function of non-de- 
structive editing, or also called the function of non-linear 
editing. This function is to provide the capability of re- 
producing any sections of AV streams in a desired order 
without actual movement or copy of the AV streams re- 
corded on the disk, and this function is achieved by cre- 
ating infomnation (playback management infomriation) 
that indicates the start and end of every section to be 
reproduced in AV streams and their order of reproduc- 
tion and implementing reproduction following that infor- 
mation. 

[0003] In this way, with such disk media, it is possible 
to make an edit without rewriting source material or mov- 
ing the data. However, there are some cases where the 
source material needs to be directly edited. For exam- 
ple, suppose the non-destructive edited result is wanted 
to be brought together into a single file for easy handling 
by a personal computer (PC). In this case, only that be- 
ing used in the edited result should be picked out from 
associated AV streams and united into a single file. 
[0004] There is also a case where an intermediate 
part that is unnecessary in an AV stream is wanted to 
be deleted in order to increase the empty capacity of the 
disk. In this case, the parts located before and after the 
intennediate part should be united. 
[0005] For either case, plural AV streams should be 
put together. However, there is a concern that some re- 
production noise might occur at the seam when a video 
data encoding scheme based on the MPEG video 
standard (ISO/lEC 11172-2 or ISO/IEC 13818-2) is 
adopted. 

[0006] The reason is as follows. The MPEG video 
standard adopts variable length coding, and this speci- 
fies that encoding of data to be coded at a predeter- 
mined rate is implemented such that a model hypothet- 
ical decoder called VBV (Video Buffering Verifier) which 
should be connected to the output from the encoder will 
not overflow or underflow. 

[0007] In this model, coded data is supplied to the 
VBV buffer at a rate not greater than the aforementioned 
predetermined rate, and the amount of data occupied in 
the VBV Increases at that rate. On the other hand, the 
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moment one frame or field has been decoded, the oc- 
cupancy of data decreases instantly by the amount of 
the corresponding coded data. 
[0008] Any coded data based on MPEG video cannot 
be assured to be reproduced correctly if the data has 
not been encoded In such control that the VBV buffer 
will not overflow or underflow even if the amount of data 
repeatedly increases and decreases, as shown in Fig. 
22. The risk of reproduction noisewhen some pieces of 
video data are joined can be attributed to the possibility 
of the VBV buffer causing overflow or underflow at a 
point of the seam. 

[0009] The reason for the collapse of the VBV buffer 
at the seam will be described referring to an example. 
Here, description is made of a case where the front part 
before time OUT of coded video data Ahaving a time- 
dependent variation in the occupancy of the VBV buffer 
shown in Fig.23 (a) and the rear part after time IN of 
coded video data B shown in Fig.23 (b) are joined. 
[0010] Fig.23 (c) is the joined result. It is understood 
that in this case the buffer underflows because a frame 
or field containing a large amount of coded data takes 
place right after the point of junction regardless of the 
low buffer occupancy right before the joined point. The 
reason why an event of this kind happens is that there 
is a possibility that the confomilty of the buffer occupan- 
cy is lost. 

[0011] In order to solve the above problem, Japanese 
Patent Application Laid-open Hei 9 No. 182024 propos- 
es a technique of preventing underflow by increasingthe 
transfer speed of the input data to the decoder. Howev- 
er, this method needs a special decoder, resulting in cost 
disadvantage. 

[001 2] As another method, Japanese Patent Applica- 
tion Laid-open Hei 8 No.251582 proposes a technique 
(re-coding) whereby the seam portion upon joining is 
once decoded and then encoded again so that the 
amount of the coded data will be kept so as not to cause 
corruption of the VBV buffer. However, in this case, there 
is a concern of occurrence of image degradation due to 
the re-coding process. Further this method needs to im- 
plement coding and decoding successively or in paral- 
lel, entailing the problem in that the apparatus becomes 
more complicated. 

[0013] The present invention has been devised in 
view of the above problems. It is therefore an object of 
the present invention to provide a data recording meth- 
od, a data editing method and a data decoding method 
as well as a data recorder and a data decoder, which, 
by a simple configuration, can prevent reproduction 
noise upon reproduction of an AV stream which is 
formed of joined AV streams. 

Disclosure of Invention 

[001 4] The first invention of the present application is 
a data recording method for recording a second unit 
composed of a plurality of first units containing first data 
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having at least video or audio and a first program that 
manages the second unit, onto a recording medium, and 
is characterized in that the first program contains infor- 
mation that manages a point of junction between the first 
units. 

[0015] The second Invention of the present applica- 
tion is characterized in that the point of junction is a site 
where arbitrary pieces of the first data are deleted from 
the second unit. 

[0016] The third Invention of the present application 
Is characterized in that the second unit is managed by 
a single file. 

[001 7] The fourth invention of the present application 
is characterized in that the first data of video is encoded 
data of the video based on a MPEG standard. 
[001 8] The fifth Invention of the present application Is 
a data editing method for producing a second unit by 
connecting a first unit containing first data having at 
least video or audio and a third unit containing second 
data having at least video or audio and is characterized 
In that a first program that manages the second unit con- 
tains Infonmation that manages a point of junction be- 
tween the first unit and the third unit. 
[0019] The sixth invention of the present application 
is characterized In that the first unit and the third unit are 
formed by deleting arbitrary pieces of the first data from 
the second unit. 

[0020] The seventh Invention of the present applica- 
tion is characterized in that the second unit Is managed 
by a single file. 

[0021 ] The eighth Invention of the present application 
is characterized in that the first and second data of video 
is encoded data of the video based on a MPEG stand- 
ard. 

[0022] The ninth Invention of the present application 
is a data decoding method for decoding a second unit 
composed of a plurality of first units containing first data 
having at least video or audio, in accordance with a first 
program that manages the second unit, and is charac- 
terized In that the first program contains information that 
manages a point of junction between the first units, and 
decoding of the first units is controlled with reference to 
the information on the point of junction. 
[0023] The tenth invention of the present application 
is characterized in that decoding control of the first units 
Is achieved by halting the decoding at the point of junc- 
tion. 

[0024] The eleventh invention of the present applica- 
tion is characterized in that decoding control of the first 
units is achieved by switching decoders before and after 
the point of junction. 

[0025] The twelfth Invention of the present application 
is characterized in that the first and second data of video 
Is encoded data of the video based on a MPEG stand- 
ard. 

[0026] The thirteenth invention of the present applica- 
tion is a data recording device for recording a second 
unit composed of a plurality of first units containing first 



data having at least video or audio and a first program 
that manages the second unit, onto a recording medium, 
and Is characterized In that the first program contains 
information that manages a point of junction between 
5 the first units. 

[0027] The fourteenth Invention of the present appli- 
cation is a data editing device for producing a second 
unit by connecting a first unit containing first data having 
at least video or audio and a third unit containing second 
data having at least video or audio, and is characterized 
In that a first program that manages the second unit con- 
tains Information that manages a point of junction be- 
tween the first unit and the third unit. 
[0028] The fifteenth invention of the present applica- 
tion is a data decoding device for decoding a second 
unit composed of a plurality of first units containing first 
data having at least video or audio in accordance with 
a first program that manages the second unit, and is 
characterized in that the first program manages infor- 
mation on a point of junction between the first units, and 
the data decoding device comprising: a decoder for the 
first units for controlling the decoding based on the In- 
formation on the point of junction. 
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25 Brief Description of Drawings 
[0029] 

Fig.1 is a block diagram showing a schematic con- 

30 figuration of a video disk recorder in the embodi- 
ment of the present Invention. 
Fig .2 is an illustrative view showing the relationship 
between the management Infonnation In the Quick- 
Time file format and AV streams. 

35 Fig.3 is an illustrative view showing the scheme of 
a Movie atom In the QuickTime file fomnat. 
Fig.4 Is an illustrative view showing the scheme of 
a Track atom In the QuickTime file fomnat. 
Fig. 5 is an illustrative view showing the scheme of 

40 a Track header atom in the QuickTime file format. 
Fig. 6 Is an illustrative view showing the scheme of 
a Media atom In the QuickTime file fomnat. 
Fig. 7 Is an illustrative view showing the scheme of 
a Media Information atom In the QuickTime file for- 

45 mat. 

Fig. 8 is an illustrative view showing an example of 
data management by a Sample table atom. 
Fig. 9 is an illustrative view showing the scheme of 
a Sample table atom in the QuickTime file format. 

50 Fig. 1 0 is an illustrative view showing the scheme of 
an Edit atom In the QuickTime file format. 
Fig. 11 is an illustrative view showing an example of 
playback range destination by an Edit atom. 
Fig. 12 is an illustrative view showing the scheme of 

55 a User-defined data atom in the QuickTime file for- 
mat. 

Fig.1 3 is an illustrative view showing a stream struc- 
ture in the first embodiment of the present invention. 
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Fig.1 4 is an illustrative view showing a VU structure 
in the first embodiment of the present invention. 
Flg.1 5 Is an iilustrative view showing an AV stream 
management structure based on QuickTime in the 
first embodiment of the present invention. 
Fig.1 6 is a flowchart showing the recording opera- 
tion in the first embodiment of the present Invention. 
Fig.1 7 is an illustrative view showing a joined state 
of AV streams in the first embodiment of the present 
invention. 

Fig. 18 Is an illustrative view showing the first ex- 
ample of an infomriatlon structure that manages the 
junction of AV streams in the first embodiment of 
the present invention. 

Fig.1 9 is an illustrative view showing the second ex- 
ample of an information structure that manages the 
junction of AV streams in the first embodiment of 
the present invention. 

Fig. 20 is an illustrative view showing the third ex- 
ample of an information structure that manages the 
junction of AV streams in the first embodiment of 
the present invention. 

Fig.21 is a flowchart showing the playback opera- 
tion in the first embodiment of the present invention. 
Fig.22 is an illustrative view showing an example of 
change in the occupancy of the VBV buffer. 
Fig.23 Is an illustrative view showing an example of 
the junction of MPEG video streams, according to 
the prior art. 

Best Mode for Carrying Out the Invention 

[0030] Herein, the embodiments of the present inven- 
tion will be described in detail with reference to the draw- 
ings. 

<System configuration> 

[0031 ] Fig. 1 shows a configuration of a video disk re- 
corder capable of dubbing, used in common in the em- 
bodiments herein. As shown In Fig.1, this apparatus Is 
comprised of a bus 100, a host CPU 101, RAM 102, 
ROM 1 03, a user interface 1 04, a system clock 1 05, an 
optical disk 1 06, a pickup 1 07, an ECC decoder 1 08. an 
ECC encoder 109, a playback buffer 110, a recording/ 
dubbing buffer 111, a demultiplexer 112, a multiplexer 
113, a multiplexing buffer 114, an audio decoder 115, a 
video decoder 116, an audio encoder 117, a video en- 
coder 118 and unillustrated camera, microphone, 
speaker, display and the like. 

[0032] Host CPU 1 01 communicates through bus 1 00 
with demultiplexer 112, multiplexer 113 and pickup 107 
as well as audio decoder 115, video decoder 116, audio 
encoder 1 1 7 and video encoder 118, though not shown. 
[0033] Upon reproduction, data read out from optical 
disk 106 by means of pickup 107, is error corrected by 
ECC decoder 1 08 and stored temporarily into playback 
buffer 110. Demultiplexer 112, in accordance with data 



transmission requests from audio decoder 115 and vid- 
eo decoder 1 1 6, distributes the data in the playback buff- 
er to associated decoders depending on the types. 
[0034] In recording, compression-coded data by au- 

5 dio encoder 1 1 7 and video encoder 1 1 8 is once sent to 
multiplexing buffer 114, AV-muitiplexed by multiplexer 
1 1 3 and then sent to recording/dubbing buffer 111. Data 
in recording/audio dubbing buffer 1 1 1 is added with error 
correction code by ECC encoder 109, then is recorded 

10 onto optical disk 1 06 via pickup 1 07. 

[0035] The coding scheme for audio data employs 
MPEG-1 Layer-ll while the coding scheme for video da- 
ta employs MPEG-2. 

[0036] The optical disk 1 06 is assumed to be a remov- 
15 able optical disk wh ich is recorded and played back spi- 
rally from the periphery toward the center. One sector Is 
made up of 2048 bytes and sixteen sectors fonn one 
ECC block for error con-ection. If any data In an ECC 
block needs to be rewritten, it is necessary to read out 
the whole ECC block containing that data, subject it to 
error correction, renew the target data, add enror correc- 
tion codes to the data again to reconstruct an ECC block 
and record it onto the recording medium. 
[0037] Further, in order to improve the recording effi- 
ciency, ZCAV (Zone Constant Angular Velocity) is 
adopted so the recording area Is composed of multiple 
zones having different rotational rates. 

<Filesystem> 

[0038] A f ilesystem is used to manage various pieces 
of information on optical disk 106. As the fiiesystem 
here, UDF (Universal Disk Fonnat) is used taking into 
account joint operation with PCs. On the fiiesystem, 
each piece of management infonnatlon and an AV 
stream Is handled as a file. The user area Is managed 
by logical blocks of 2048 bytes (one to one correspond- 
ent with the sectors). 

[0039] Each file is composed of an integer number of 
extents (consecutive logical blocks) and can also be dis- 
persed out and stored in extent units. The empty areas 
are managed in logical block units using Space Bitmap. 
[0040] The information showing extents, the Space 
Bitmap, the management infomriation as to the fiiesys- 
tem and the like are recorded on optical disk 1 06. 

<Flle fomiat> 

[0041] As the format for management of AV streams, 
the QuickTime file format Is used. The QuickTime file 
format was developed as a fomnat for multimedia data 
management by Apple Computer, Inc., and is widely 
used In the PC world. 

[0042] The QuickTime file format is composed of vid- 
eo data, audio data and the like (these are also called 
media data) and management information. The combi- 
nation of these two Is herein called a QuickTime movie 
(abbreviated as movie). The two may be present in the 
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same file or in different files. 

[0043] When present in the same file, they constitute 
a file 201 shown in Rg.2(a). Each piece of infonnatlon 
is stored as a common structure called an atom. The 
management infomiatlon is stored as a structure called 
Movie atom. The AV stream is stored as a structure 
called Movie data atom. 

[0044] It should be noted that a Movie atom is a kind 
of program infonnation for controlling playback of arbi- 
trary sections of media data in an arbitrary order, and 
includes a table for providing a relative position, In the 
file, of the AV data that corresponds to an arbitrary time 
in the media data, the attribute information of the media 
data, and external reference infonnation, which will be 
described hereinbelow. 

[0045] When management information and media da- 
ta are stored in different files, they constitute a stmcture 
of files 202 and 203 shown in Fig.2{b). The management 
infonnation is stored as a structure called Movie atom 
while the AV stream is not needed to be stored as an 
atom. In this situation it is termed that the Movie atom 
'externally refers' to file 203 holding the AV stream. 
[0046] External reference, as shown in Fig. 2(c), can 
be made such that the Movie atom of file 204 can refer 
to AV stream files #1 and #2 disposed in plural files 205 
and 206. This structure enables so called 'non-linear ed- 
iting' or 'non-destructive editing' which achieves simu- 
lated editing without making physical movement of any 
AV streams. 

[0047] Now, the QuickTime management infonnation 
fonnat will be described with reference to Figs. 3 to 12. 
To begin with, the common infonnation storage fonnat, 
i.e., atom, will be explained. Each atom necessarily in- 
cludes Atom size that indicates the size of the atom and 
Type that indicates the type information of the atom at 
the front thereof. Type is represented with four charac- 
ters, for example, 'moov' depicts a Movie atom, 'mdat' a 
Movie data atom. 

[0048] Each atom can contain another atom. That is, 
atoms can constitute layered structures. Fig. 3 shows 
the structure of a Movie atom. A Movie header atom 
manages the overall attributes of the movie which the 
Movie atom manages. A Track atom stores the informa- 
tion as to the track of video, audio and the like contained 
in that movie. A User-defined data atom is an atom 
which can be defined in a free fashion. 
[0049] Fig. 4 shows the structure of a Track atom. A 
Track header atom manages the overall attributes of the 
track. An Edit atom manages at what timing a section of 
media data should be reproduced in the movie. A Track 
reference atom manages the relationship with other 
tracks. A Media atom manages actual data such as vid- 
eo and audio data. 

[0050] Fig.5 shows the structure of a Track header at- 
om. Here, description will be made as to only those 
needed hereinbelow. ' Flags' is a group of flags indicating 
attributes. As a typical example, Track enabled flag can 
be mentioned. If this flag Is 1. the track is reproduced 



while the track Is not reproduced if it is 0. Layer indicates 
the spatial priority of the track. If there are multiple tracks 
that display images, the smaller the layer value of a 
track, the more to the foreground the conresponding im- 
5 age is displayed. 

[0051] Fig.6 shows the structure of a Media atom. A 
Media header atom manages the overall attributes etc. 
as to the media data the Media atom manages. A Han- 
dler reference atom stores infonnation that represents 
which decoder the media data should be decoded by. A 
Media Infonnation atom manages attribute infonnation 
unique to the media such as video, audio etc. 
[0052] Fig. 7 shows the stmcture of a Media informa- 
tion atom. A Media infomnation header atom manages 
attribute infonnation unique to the media such as video, 
audio etc. A Handler reference atom is that explained in 
the Media atom paragraph. Data infonnation atom con- 
tains a Data reference atom, which is the atom that man- 
ages the names of files containing media data to which 
the QuickTime movie refers. A Sample table atom man- 
ages the size of data, playback time and the like. 
[0053] Next, a Sample table atom will be described. 
However, before this description, the data management 
scheme in QuickTime will be described with reference 
to a file 801 shown in Fig. 8. In QuickTime, the minimum 
unit of data (e.g., video frame) is called a sample. In 
each track, each sample is allotted with a number (sam- 
ple number) starting from 1, in the order of playback time 
sequence. 

[0054] The QuickTime format manages the playback 
time length and data size of each sample. An area In 
which samples belonging to the same track is arranged 
consecutively in a file in the order of playback time se- 
quence is called a chunk. Each chunk is also allotted 
with a number starting from 1 in the order of playback 
time sequence. 

[0055] The QuickTime file fonnat also manages the 
address of each chunk from the front of the file and the 
number of samples belonging to each chunk. Based on 
these pieces of information, it is possible to determine 
the position of a sample corresponding an arbitrary point 
of time. 

[0056] Fig. 9 shows the structure of a Sample table at- 
om. A Sample description atom is a table that manages 
the data formats of individual chunks, the indexes of files 
in which samples are stored, and the like. In this table, 
If samples are stored in different files or if there is differ- 
ence in data fonnat or in other aspects, such cases are 
managed by different entries in the table. Here, the entry 
is a unit of information which Is referred to by other in- 
formation. 

[0057] A Tlme-to-sample atom manages the playback 
time of individual samples. A Sync sample atom man- 
ages, among all the samples, those from which decod- 
ing can be started. A Sample-to-chunk atom manages 
the number of samples contained in each chunk and 
which entry in the Sample description atom each chunk 
refers to. A Sample size atom manages the size of each 
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sample. A Chunk offset atom manages the address of 
each chunk from the front of the file. 
[0058] An Edit atom contains one Edit list atom as 
shown in Fig. 10, An Edit list atom has groups (entries) 
of values of Track duration, Media time and Media rate, 
in an amount that Is designated by Number of entries. 
These entries each correspond to a section that is re- 
produced consecutively on a track and are arranged on 
the track in the order of playback time sequence. 
[0059] Track duration represents the playback time on 
the track of the section that is managed by the entry; 
Media time represents the position, in the media data, 
which con-espondsto the front of the section that is man- 
aged by the entry; and Media rate represents the repro- 
duction speed of the section that is managed by the en- 
try. When Media time Is set at -1 , playback of samples 
on that track is hatted by the time indicated by Track 
duration of that entry. This section is called empty edit. 
[0060] Fig. 11 shows a practical example of Edit list, 
where it is assumed that Edit list atom has the content 
shown in Fig.ll(a) and the sample arrangement is as 
shown In Fig.11(b). Here, Track duration, Media time 
and Media rate of the i-th entry are represented by D(i), 
T(i) and R(i), respectively. In this case, actual playback 
of samples is implemented In the order shown In Fig. 11 
(c). This will be briefly described. 
[0061 ] First, since entry #1 defines that Track duration 
Is 13000, Media time Is 20000 and Media rate is 1 (Fig. 
11(a)), the sample section from time 20000 to 33000 
(=20000+13000) (Fig.ll(b)) is played back in the track 
section from the front to 13000(Fig. 11(c)). Then, since 
entry #2 defines that Track duration is 5000 and Media 
time is -1 (Fig. 11 (a)), no data is reproduced from the 
track section from time 13000 to 18000(=1 3000+5000) 
(null in Fig.11(c)). 

[0062] Finally, since entry #3 defines that Track dura- 
tion is 10000, Media time is 0 and Media rate is 1 (Fig. 
11(a)), the sample section from time 0 to 10000 (Fig. 11 
(b)) is reproduced in the track section from time 18000 
(=13000+5000) to 28000(=1 8000+1 0000) (Fig. 11(c)). 
[0063] Fig.12 shows the stmcture of a User-defined 
data atom. This atom is able to store a desired number 
of pieces of free information that are not defined by the 
QuickTime format. A piece of free infomriation is man- 
aged by one entry, which is composed of Size, Type and 
User data. Size indicates the size of the entry itself. Type 
is an ID Information for distinguishing that free informa- 
tion from the others. User data represents actual data. 

<lndex file> 

[0064] One special QuickTime movie file called AV in- 
dex file is provided on the disk in order to manage Quick- 
Time movies contained in the disk. Registered in the AV 
index file are thumbnails and various attributes concern- 
ing files (QuickTime movies, still images referred to by 
QuickTime movies, and others) In the disk. 
[0065] One of the various attributes is Link count, 



which represents the number of times the file is refen-ed 
to from without. Checking the Link count of a file facili- 
tates the knowledge as to whether there is any file that 
refers to that file, so that it is possible to prevent acci- 
5 dental deletion of a file that is referred to from others. 

<Embodiment 1> 

[0066] One embodiment of the present invention will 
10 be described with reference to Figs. 13 to 21 . 

<AV stream structure> 

[0067] The structure of an AV stream in the present 
15 invention will be described with reference to Figs.13 and 
14. An AV stream is composed of an integer number of 
Record Units (RUs). A RU is a unit to be recorded con- 
tinuously on the disk. The lengths of RUs are set up so 
as to guarantee seamless playback (the picture and 
20 sound during playback can be reproduced without a 
break) regardless of how the RUs that constitute the AV 
stream are allocated on the disk. This setup will be de- 
scribed later. 

[0068] Further, the stream is constructed so that RU 

25 boundaries correspond to ECC block boundaries. Ow- 
ing to these RU features, the arrangement of an AV 
stream after it has been recorded on the disk can be 
easily changed by the RU units while seamless play- 
back is guaranteed. 

30 [0069] A RU is composed of an integer number of Vid- 
eo Units (VUs). A VU is a unit that is reproducible by 
itself. Therefore, it is a possible entry point upon repro- 
duction. Fig. 14 Is the structure of a VU. A VU is com- 
posed of an integer number of GOPs (groups of pic- 

35 tures) storing video data of about one second long and 
an integer number of AAUs (Audio Access Units) storing 
main audio data to be reproduced in synchronism. 
[0070] Here, GOP Is a compression unit in MPEG-2 
standard and is composed of a multiple number of video 

40 frames (typically, about 15 frames). AAU is a compres- 
sion unit in MPEG-1 Layer II standard, and is composed 
of 1 1 52 sample points of the sound wavefomi. When the 
sampling frequency is 48 kHz, the reproduction time per 
AAU is 0.024 second. 

45 [0071] In VU, AAUs and GOPs are arranged in the 
order mentioned In order to lessen the necessary delay 
to assure AV synchronized reproduction. Further, In or- 
der to permit independent reproduction in UV units, a 
Sequence Header (SH) Is allotted at the front of the vid- 

50 eo data in each VU. 

[0072] The playback time of a VU is defined by the 
product between the number of video frames contained 
in the VU and the video frame period. When an integer 
number of VUs are put together into a RU, zeros are 

55 stuffed after the end of the VUs so that the start and end 
of the RU correspond to ECC block boundaries. 
[0073] In the present embodiment, the AV stream 
structure shown in Figs.13 and 14 is used for explana- 
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tion, but the present invention should not be limited to 
this stream configuration. 

<AV stream management method> 

[0074] The management method of AV streams is de- 
vised on the basis of the aforementioned QuickTime file 
format. Flg.15 shows an AV stream management struc- 
ture by QuickTime. AAU is given as a 'sample' of audio 
data, and Sequence header and the integer number of 
GOPs are given as a 'sample' of video data. The main 
audio and the video block in VU are each made core- 
spondent to a single chunk. 

<Determining method of allocation on disk> 

[0075] The detemnining method of allotting AV 
streams on the disk wilt be described. In order to guar- 
antee seamless playback, the RU readout time includ- 
ing the time for jump to the next RU needs to be shorter 
than the playback time of a RU. 
[0076] This means that Te(i), the RU playback time, 
satisfies the following relation: 

Te(i)^Tr(i) <Eq.1> 

where Te(l) is the RU playback time, T(i) is the maxl- 
mumplayback time for an arbitrary RU in AV streams, 
namely RU#i, and Tr(i) is the maximum readout time in- 
cluding the time for discontinuous jump. 
[0077] When Ra and Rv represent the maximum bit 
rates of the main audio and video in the AV streams, Ta 
represents the maximum access time of the playback 
device and Rs represents continuous readout rate, the 
following relation holds : 

Tr(i) = Te(i) x (Rv+Ra)/Rs + Ta <Eq.2> 

[0078] From <Eq.1> and <Eq.2>, Te(i) should satisfy 
the following relation: 

Te{i) > Ta X Rs/(Rs-Rv-Ra) <Eq.3> 

[0079] Therefore, the minimum value Temin for the 
RU playback time to guarantee seamless playback is 
given as follows: 

Temin = Ta x Rs/(Rs-Rv-Ra) <Eq.4> 
<Process for recording> 

[0080] Referring to Flg.1 6, the process when record- 
ing Is commanded by the user will be described. In this 
case, it is assumed that the AV stream to be recorded 



has a video bit rate Rv=5 Mbps and an audio sampling 
frequency of 48 kHz with a bit rate Ra=:Rp=256kbps. It 
is also assumed that the management information of the 
filesystem has already been loaded into RAM. 
5 [0081] To begin with, the stream configuration and the 
arrangement of continuous areas are determined (Step 
701). When it is assumed that 1 VU is composed of 1 
GOP=30 frames, as a result of substitution of 
Rs=20IVIbps, Ta=1 sec. , Rv=5i\/lbps and Ra=256kbps 
10 into <Eq.4>, Te(i) is given to be equal to or greater than 
1 .36 sec. Since the playback time of 1 VU is 0.5 sec., 
the RU playback time is set at 2 seconds. 
[0082] Next, an empty area capable of recording two 
consecutive VUs should be searched for. Specifically, 
15 2x(Rv+Ra), or a continuous empty area equal to or 
greater than 1 1 Mbits should be searched for with refer- 
ence to Space Bitmap in RAM 102. If there is no such 
a space, the recording is stopped and failure of record- 
ing is informed to the user (Step 702). 
[0083] Audio encoder 1 1 7 and video encoder 11 8 are 
activated (Step 703). Next, it is checked whether data 
in an amount equal to or greater than one ECC block 
(32KB) is accumulated in the recording buffer (Step 
704). While data accumulation is in progress, Steps 705 
to 708 are repeated. 

[0084] When data accumulation is completed, the sta- 
tus of vacancy of the next ECC block to which data is 
recorded on the disk is checked with reference to Space 
Bitmap in RAM (Step S705). If there is no vacancy, an 
empty area capable of recording two consecutive VUs 
is searched for (Step 707) and the pickup is moved to 
the front of that empty area (Step 708). 
[0085] Next, data In the amount of one ECC block 
from recording buffer 1 11 is recorded into the disk (Step 
706). If data has not been accumulated in recording buff- 
er 11 1 , It is checked whether a recording end command 
has been given (Step S709). When recording has not 
yet ended, Step 704 is executed. 
[0086] When a recording end command has been giv- 
en, the following steps are implemented. First, the data 
in the recording buffer, in an amount under 32KB is add- 
ed at its end with dummy data to reach 32KB (Step 71 0). 
Next, the data is recorded onto the disk (Steps 711 to 
714). Finally, the QuickTime management information 
(Movie atom) in RAM 102 and the filesystem manage- 
ment infomnation are recorded on optical disk 106 
(Steps 715 to 716). 

[0087] The operations of audio encoder 117, video 
encoder 118 and multiplexer 113 which operate in par- 
allel with the above process will be described. Each of 
the encoders sends the encoded result to multiplexer 
113 and the multiplexer stores these into multiplexing 
buffer 114. 

[0088] When data amounting to 1 VU, or 1 GOP with 
AAUs to be reproduced In synchronism therewith are 
accumulated in multiplexing buffer 114, multiplexer 113 
sends out data of 1 VU to recording buffer 111 . Then, 
notice that data con^esponding to 1 VU has been encod- 
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ed is given to host CPU 1 01 , host CPU 1 01 renews the 
QuickTime management infonmation In RAM 102, 
based on the GOP that constitute the VU and the 
number and sizes of AUUs. 

< Process for editing> 

[0089] A case where data In RU units Is deleted from 
a portion partway within an AV stream will be consid- 
ered. As already mentioned, the RU boundaries con^e- 
spond to ECC blocic boundaries. Further, one ECC blocic 
is composed of 1 6 sectors, and one sector corresponds 
to one logical blocic. Accordingly, It is possible to delete 
RU units of data by only rewriting the filesystem man- 
agement infomnation and the QuickTime management 
infomiatlon. 

[0090] As to the filesystem management infomnation, 
those bits that correspond to the area to be deleted, in 
the aforementioned Space bitmap, are set at 0 to there- 
by release the area while the extents that manage the 
RUs to be deleted are rewritten. As to the QuickTime 
management infomiation, the samples contained in the 
section to be deleted are deleted from the Sample table 
and the Chunk offset value of the chunk located after 
the section to be deleted is reduced by the number of 
bytes of the deleted section. 

[0091] Further, with the reduction in playback time of 
each track due to deletion, Track duration of Edit list 
(Figs. 10 and 11) should be shortened (Figs. 10 and 11). 
By the above deletion, the resulting AV stream is formed 
so that the points right before and right after the deleted 
section are joined. At the same time, as to the video 
track, in orderto demonstrate the seam, different entries 
are allotted before and after the point of time con-e- 
spending to the seam between the areas before and af- 
ter the seam. 

[0092] For example, when AV streams #1 and #2 are 
joined so as to constitute an AV stream as shown In Fig. 
17, Edit list atom (Fig. 10) Is defined by two entries as 
shown in Fig. 18. Also, a case where AV streams are 
joined to one another in RU units can be also handled 
in a similar manner to that of deletion, i.e., by rewriting 
the filesystem management Infomiation and the Quick- 
Time management Infonnation. From this Infomnation, 
the point of time at the seam along the track time axis 
and the address of the corresponding data of the time 
in the file can be known. 

[0093] Though In the present embodiment, a case in- 
cluding one seam was described, It goes without saying 
that a case including two or more seams can be dealt 
with by only increasing the number of entries. 
[0094] In the above case, the seam is made distinct 
by switching the entries In the Edit list of one track of 
video. However, any method can, of course, be used as 
long as it is possible to make distinct the possible sites 
that originate from the junction of AV streams and that 
may hinder decoding and reproduction. To cite one ex- 
ample, seams can be indicated by switching video 



tracks every seam. 

[0095] Illustratively, in a case where AV streams 
shown in Fig. 17 are created by a joining process, the 
seam can be made distinct by managing the front half 
5 and the rear half using different tracks in such a manner 
that the contents of the Edit list atoms (Fig. 10) of the 
tracks that manage the front and rear halves are desig- 
nated respectively as shown in Figs. 19(a) and 19(b). In 
this case, in order to prevent accidental integration of 
10 the video tracks #1 and #2 after post editing, at least 
one value, specifically, Creation time (Flg.5) or the like, 
Is made different between video tracks #1 and #2. 
[0098] Alternatively, the seam may be demonstrated 
by making the content of Sample description atom (Fig. 
15 9) different between that before and after the seam. 
Specifically, In a case where AV streams shown In Fig. 
17 are created by a joining process, the video data of 
the AV stream #1 and the video data of the AV stream 
#2 are adapted to refer to separate attributes represent- 
ee edby different entries #1 and #2 in Sample description 
atom, as shown in Fig.20. 

[0097] In this way, Itispossibletoshowtheseam. Fur- 
ther, by differentiating at least one value of each entry 
from that of the other in Sample description atom, It Is 
25 possible to prevent the entries #1 and #2 from being ac- 
cidentally merged when the Sample description table is 
optimized (plural entries having common content are in- 
tegrated into one) at a later editing process. 

30 <Process for playback> 

[0098] The process when a playback command is giv- 
en from the user will be described with reference to Fig. 

21 . Here, it is assumed that the QuickTime management 
35 information on the AV stream to be reproduced has al- 
ready been loaded Into RAM 1 02. 
[0099] Playback data starts being read from the front 
of a designated VU on optical disk 106 for playback 
(Step 901). This step 901 Is repeated until a sufficient 
40 time of playback data has been loaded to playback buff- 
er 110 (Step 902). 

[0100] 'A sufficient time of playback data' herein 
means the amount of data that will not cause any break 
during playback even when the maximum interruption 
45 occurs during readout of playback data. Specifically, the 
amount of data for 1 second is secured assuming that 
a discontinuous jump (maximum 1 second) entailing the 
readout of AV data is made. 

[0101] Next, host CPU 101 activates video decoder 
50 116 and audio decoder 1 1 5 (Step S903). Host CPU 1 01 , 
based on the QuickTime management information, 
gives a command to demultiplexer 1 12 so as to transfer 
the encoded data from playback buffer 110 to audio de- 
coder 115 and video decoder 116. 
55 [0102] Also, it is checked whether a playback end 
command has been given from the user (Step 904). If 
no command is given, playback AV data Is read out 
(Step 905). If the playback end command has been giv- 
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en, the operation is ended. 

[0103] When host CPU 101 , based on system clock 
105, detects that the current tinne reaches the time for 
switching the entries (Fig. 1 1 ) of Edit list atom (Fig. 1 0) of 
the video track, it determines that the site is a seam and 
halts the decoding operations by video decoder 1 1 6 and 
audio decoder 115. When change of the entries in Sam- 
ple description table (Fig.20) to which the video chunks 
refer is made use of to Indicate a seam, the site at which 
change of the entries occurs is determined to be a seam. 
[0104] Though the above operation causes the video 
frame right before the seam to be displayed (frozen) 
multiple times consecutively, no buffer underflow will oc- 
cur because data can be accumulated into the decoder 
buffer for video decoder 116 during this period. There- 
fore, no reproduction noise will occur for some time, un- 
like the decoder buffer underflows. Further, since the 
video picture across a seam Is inherently discontinuous, 
a freeze, if it occurs, will not cause noticeable noise com- 
pared to the same event at any other site. 
[0105] Though In the present embodiment a single 
video decoder is used, a multiple number of video de- 
coders may be used to make a switch at a seam. Spe- 
cifically, the following operation Is effected upon play- 
back. Because the position of an actual seam In the AV 
data is known from the change of the entries in Edit list 
atom of the video track, the video data after the seam is 
sent to other video decoder than that used before the 
seam and starts being decoded so that the data can be 
displayed at any time. Then, when it reaches the point 
in time at which the entries of Edit list atom are switched, 
the video decoders are switched from that before the 
seam to that after the seam. In this case, since different 
decoders are used before and after the seam, no dis- 
continuity of the occupancy of the VBV buffer will occur, 
and it is no longer necessary to freeze the display as in 
the case where only a single video decoder is used. 
[01 06] Though in the present embodiment the seams 
generated during editing are handled, the seams to be 
managed by the present invention are not limited to only 
those arising during editing. For example, when record- 
ing of a new AV stream is added after the end of an ex- 
isting AV stream file, a discontinuity of the amount of 
occupancy of the VBV buffer occurs between the point 
before and after the point of addition. If the AV stream 
file is reproduced as is, there is a risk of noise occurring 
in decoding and reproduction right after the point of ad- 
dition. Management of the point of addition in the same 
manner as in the present embodiment makes it possible 
to prevent such decoding and reproduction noise. 
[0107] As has been described heretofore, according 
to the present invention, when multiple AV streams are 
put together Into a single AV stream, the positional In- 
formation of the seams are managed by the manage- 
ment information that manages the AV stream. Thereby 
it is possible to prevent the display from being disturbed 
around the seams when reproduced. 



Industrial Applicability 

[0108] When AV streams of video data, audio data, 
etc., are recorded into a random accessible recording 
5 medium such as a hard disk, optical disk or the like and 
decoded therefrom, the invention is suitable for data re- 
cording, editing and decoding methods and a device 
thereof that can prevent playback data noise occurring 
between the AV streams. 



Claims 

1 . A data recording method for recording a second unit 
^5 composed of a plurality of first units containing first 

data having at least video or audio and a first pro- 
gram that manages the second unit, onto a record- 
ing medium, 

characterized in that the first program contains in- 
20 formation that manages a point of junction between 
the first units. 

2. The data recording method according to Claim 1 , 
wherein the point of junction Is a site where arbitrary 

25 pieces of the first data are deleted from the second 
unit. 

3. The data recording method according to Claim 1 or 
2. wherein the second unit is managed by a single 

30 file. 

4. The data recording method according to Claims 1 
through 3, wherein the first data of video is encoded 
data of the video based on a MPEG standard. 

35 

5. A data editing method for producing a second unit 
by connecting a first unit containing first data having 
at least video or audio and a third unit containing 
second data having at least video or audio, 

40 characterized in that a first program that manages 
the second unit contains infomnation that manages 
a point of junction between the first unit and the third 
unit. 

45 6. The data editing method according to Claim 5, 
wherein the first unit and the third unit are fonmed 
by deleting arisitrary pieces of the first data from the 
second unit. 

50 7. The data editing method according to Claim 5 or 6, 
wherein the second unit is managed by a single file. 

8. The data editing method according to Claims 5 
through 7, wherein the first and second data of vid- 

55 eo is encoded data of the video based on a MPEG 
standard. 

9. A data decoding method for decoding a second unit 
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composed of. a plurality of first units containing first 
data having at least video or audio, in accordance 
with a first program that manages the second unit, 
characterized In that the first program contains in- 
formation that manages a point of junction between 5 
the first units, and decoding of the first units is con- 
trolled with reference to the infonnation on the point 
of junction. 

10. The data decoding method according to Claim 9, io 
wherein decoding control of the first units is 
achieved by halting the decoding at the point of 
junction. 

11. The data decoding method according to Claim 9, is 
wherein decoding control of the first units is 
achieved by switching decoders before and after 
the point of junction. 

12. The data decoding method according to Claims 9 20 
through 1 1 , wherein the first and second data of vid- 
eo is encoded data of the video based on a MPEG 
standard. 

13. A data recording device for recording a second unit 25 
composed of a plurality of first units containing first 
data having at least video or audio and a first pro- 
gram that manages the second unit, onto a record- 
ing medium, 

characterized in that the first program contains in- 30 
formation that manages a point of junction between 
the first units. 

14. A data editing device for producing a second unit 

by connecting a first unit containing first data having 35 
at least video or audio and a third unit containing 
second data consisting of at least video or audio, 
characterized in that a first program that manages 
the second unit contains information that manages 
a point of junction between the first unit and the third "^o 
unit. 

15. A data decoding device for decoding a second unit 
composed of a plurality of first units containing first 
data having at least video or audio In accordance 
with a first program that manages the second unit, 
wherein the first program manages infomnatlon on 
a point of junction between the first units, the data 
decoding device comprising: 

50 

a decoder for the first units for controlling the 
decoding based on the infonnation on the point 
of junction. 
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FIG. 5 
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FIG. 9 
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FIG. 10 
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FIG. 12 
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FIG. 17 
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FIG. 21 
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